As a network grows, inevitably you'll need to make changes to the TCP/IP addressing scheme. In this process, you might end up adding equipment that stretches the original scheme to the limit. Or your company might acquire another company with an IP addressing scheme that conflicts with yours. With a bit of planning and a methodology in place, you can make this process easier by quickly getting your IP addressing scheme cut over so that you can become part of the bigger network and not a sore spot on the topology map. Here’s how to do it.

Get ready
Before beginning, you’ll need to do a bit of advance work. Make sure you cover all bases, including the following:


Plan and design
To start, you need to build a solid topology map. Often, many networks today suffer from poorly kept and inadequately updated network documentation, so you’ll need to make sure you aren’t working with this type of documentation. You need to know what the network looks like from a very high level so you don't miss anything. In Figure A, you can see how simple it is to make a quick map to ensure that you don’t miss any segment or devices on your network. I have outlined a simple network map here, but you can make this as complex as you need to, depending on what you need to see and the size of your network.

Figure A

You’ll need to make a basic topology map like this one.



The whole point of the map is that you can attack sections of the network as a whole. On my map, I have outlined sections labeled with numbers. Here is a breakdown of those sections:


With a map of your network in hand, you can easily create a spreadsheet, hand out team assignments, and assign sections of the LAN to be cut over by team members.

To further plan this cutover, involve the entire MIS staff. Make sure you involve everyone who is responsible for applications and systems so that when you flip the switch, you have people around that will be able to help on a very granular level. For example, you may have an application on a mainframe that has a hard-coded IP address on it. If you need that changed (something you may not have planned for), you will, of course, need help from whoever has access to that system and whoever knows how to change the application as well.

Next, to get your spreadsheets in order with the current IP addressing scheme, you need to add the following to the spreadsheets:


Once you have this spreadsheet, similar to the one in Figure B, you can add the new range next to it and you are ready to go.

Figure B

Here is an example of a LAN addressing spreadsheet.



Now that your documentation is coming together, make sure you can get the plan out to others by developing a project plan. You do not need to specifically use Microsoft Project, but you can if you have it available. In any case, you need a documented plan, and since you will be making a severe change on the network, you will have to implement a change control procedure.

Change control is the documentation of what currently exists on the plan. This is augmented by strict backout plans. In other words, if the project fails, you then have a documented fallback plan. Most likely, the reverse of the cutover plan will be the backout plan. Be certain that everyone knows how to fall back if you run into a major problem.

Make sure you are not forgetting anything. Remember, all networks are different, and it is wise to have senior network personnel available to help you through this if you don't know the network very well. When you flip the switch, you may be faced with some problems, such as applications that don’t work because you didn’t think about the network’s impact on them.

Static assignments
Once you have the documentation in place, have assembled the team, and have gathered your nerves of steel, it’s time to begin the cutover. Your next step is to deal with the hard-coded devices on the network. Hard-coded simply means that the addresses assigned do not change and are not handed out by DHCP. If you want them to be changed, you must change them manually. This is not a bad thing, because when you are using printers, routers, servers, and anything else that you go to for resources as a client, you want the address to always be the same. If a server that you access by IP address suddenly gets a new address from DHCP, then you are not going to be able to get to it.

With this in mind, you now have a problem with cutting over your network from one IP address range to another. Because of the hard-coded nature of these addresses, you will have to visit each server and manually add the addresses. If you have a LAN with two or three servers, this is not a big deal, but what about networks that have 10 servers, 20 printers, and many more static devices?


You could schedule a day's worth of downtime to get them all changed over, or you could add another IP address to them all so they could be accessed by both IP address ranges. To explain this second example, let’s look at how to statically assign two IP addresses to a Cisco router and also to a Windows 2000 server.

Applying secondary addressing to a Cisco router
To assign multiple IP addresses to network interfaces, use the following command in interface configuration mode, as shown here:
Router (config-if)#ip address ip-address mask secondary

It may look like this:
Router (config-if)#ip address 10.0.0.1 255.255.255.0 secondary

Applying secondary addressing to a Windows 2000 server
You can also add a second IP address and a default gateway to your servers in Windows 2000 by first viewing your network properties and then selecting the TCP/IP protocol stacks properties. You can then add your secondary addressing, as shown in Figure C.

Figure C

Here is an example of adding a second IP address to a Windows 2000 server.



As you can see, adding a second IP address allows you to seamlessly integrate a LAN segment from one address range to another without causing chaos to your client community. Now that you have all of your devices statically set with the new range, it’s time to work on the clients.

Dynamic addressing
Most network clients get their addresses from DHCP. It’s easier and more manageable to use DHCP for client workstations than statically assigning them. Addresses are doled out via a scope. A scope, as shown in Figure D, is what you need to rebuild in order for your network to finish the cutover. To rebuild a scope in Windows 2000, you can simply get your new scope up and ready—but don’t activate it. In other words, you can have your regular scope still functional and build a new one in the console, get it ready to go, but leave it inactive.

Figure D

Here is the Windows 2000 DHCP scope.



In Figure D, you can see that the normal scope in use (192.168.100.0) is operational, and the new scope has a red arrow indicating that it is Inactive. In the right-hand side of the DHCP MMC, you will see the details of what was just explained. All you need to do is right-click the old scope and select Deactivate from the Properties menu. Next, right-click the new scope you want to use and select Activate.

Normally, it may take awhile to have your systems on the LAN renew their addresses, so what I normally do for a shortcut before deactivating the scope is look at the Address Leases icon and disconnect any users still seen in the console. This ensures that those users will be off the old range. One last tip is to have everyone shut down their systems before leaving work when you plan to do this cutover. When the users come back in to work, they will boot up and get a brand new IP address from the new range.


Author’s tip
I suggest statically setting up all secondary IP addressing and running massive tests on connectivity with a single host on your network. You should do this before cutting over the rest of your clients by rebuilding the scopes. You may be missing things that you won’t come across until you test.



Test out the new subnet scheme
Before you call it a victory, you should make sure every application works and check all your system logs (routers, switches, Event Viewer logs on your servers, and so on). You may have some issues where you need to clear out ARP caches on your switches or other devices because they will hold IP to MAC address mappings that will not exist when the cutover is done. Test all your systems and alert your help desk that it might be getting some calls about issues resulting from your cutover.